| Package | ForgePatientChart.0830 |
| Type | StructureDefinition |
| Id | Id |
| FHIR Version | R4 |
| Source | https://simplifier.net/resolve?scope=ForgePatientChart.0830@0.1.0&canonical=http://telus.com/fhir/patientChart/StructureDefinition/profile-medication-statement |
| Url | http://telus.com/fhir/patientChart/StructureDefinition/profile-medication-statement |
| Status | draft |
| Date | 2021-03-22T16:05:12.5060946+00:00 |
| Name | MedicationStatement |
| Title | Medication Statement Patient Chart |
| Experimental | False |
| Authority | hl7 |
| Description | This profile is scoped for usage within the Patient Chart |
| Type | MedicationStatement |
| Kind | resource |
No resources found
| StructureDefinition | |
http://telus.com/fhir/patientChart/StructureDefinition/ext-rendered-dosage-instruction  | Ext Rendered Dosage Instruction |
FHIR{
"resourceType" : "StructureDefinition",
"id" : "profile-medicationStatement-patientchart",
"meta" : {
"versionId" : "4",
"lastUpdated" : "2022-08-30T17:47:06.4712497+00:00"
},
"url" : "http://telus.com/fhir/patientChart/StructureDefinition/profile-medication-statement",
"name" : "MedicationStatement",
"title" : "Medication Statement Patient Chart",
"status" : "draft",
"date" : "2021-03-22T16:05:12.5060946+00:00",
"description" : "This profile is scoped for usage within the Patient Chart",
"fhirVersion" : "4.0.1",
"mapping" : [
{
"identity" : "workflow",
"uri" : "http://hl7.org/fhir/workflow",
"name" : "Workflow Pattern"
},
{
"identity" : "rim",
"uri" : "http://hl7.org/v3",
"name" : "RIM Mapping"
},
{
"identity" : "w5",
"uri" : "http://hl7.org/fhir/fivews",
"name" : "FiveWs Pattern Mapping"
},
{
"identity" : "v2",
"uri" : "http://hl7.org/v2",
"name" : "HL7 v2 Mapping"
}
],
"kind" : "resource",
"abstract" : false,
"type" : "MedicationStatement",
"baseDefinition" : "http://hl7.org/fhir/StructureDefinition/MedicationStatement",
"derivation" : "constraint",
"differential" : {
"element" : [
{
"id" : "MedicationStatement",
"path" : "MedicationStatement",
"comment" : "***** Add adherence code extension\r\n\r\nConformance Rule: If the EMR is able to distinguish that the patient was the source/data enterer of the medication information (eg entered by the patient in the patient portal or into a e-questionnaire/qnaire), this must be conveyed as a Medication Statement. Example: Questionnaire may capture existing drugs. This is a potential use case where an EMR is able to distinguish that the patient is the source of the information.\r\n\r\nConformance Rule: A medication Statement will always trigger the creation of a plan; as a plan is required in order to convey changes in status, eg on-hold, stopped, etc \r\n\r\nConformance Rule: A medication statement is only to be used when EMRs can detect that the patient is the information source. It is not always possible for the EMR to distinguish the patient/related person as the information source is not alwasy recorded discretely. In this case the key data (eg patient not taking due to side effect) will be captured on the plan as a note. \r\n\r\nConformance Rule: The status of a medication statement will always be set to \"complete\"\r\n\r\n\r\nTO BE REVIEWED --- Patient Chart Usage Guidelines: \r\n1. In the context of sending a consultation request/referral it is usually not necessary to send the Prescription information along with the Medication Statement. . Prescription details may be very important when referring to an oncologist, or to share dose, interval frequency (once a day)\r\n2. There will be a medication statement for each new SIG. There will be a new medication statement for each status change (eg on hold, discontinued).\r\n\r\n3. A single med statement could include multiple prescriptions; OR multiple medication statements may reference a single prescription (eg dose change) OR a medication statement may be sent without a prescription (eg prescribed by specialist, non-prescription (eg aspirin) or prescribed medication that was reported by the patient or a mediication that was started by another doctor (aka external prescription).\r\n\r\n4. Type of Medication Statements: 1. A patient chart will cover a period of time that a patient was on the same dose of a medication. 2. Dose changes over a fixed schedule, over a period of time as specified in the presciption dosage instructions (eg warafin). If there is a new SIG, there will be a new medication statement. 3. PRN - this is a valid medication period\r\n\r\n6. Conformance Rule: If the patient follows the dose on the prescription, we would expect a single medication statement which may have multiple dosage lines. If the dose changes unexpectedly, or in a way that was not indicated on the original SIG, there will be multiple medication statements; one for each consecutive period and dosage instructions for that period.\r\n\r\nCONFIRM: NEW MED STATEMENT WHEN WE CHANGE DOSAGE\r\n\r\n\r\n\r\nDW - Use Case\r\n\r\nExample - Warafin - a patient on warafin could be represented by multiple medication statements; one for each interval of time/dosage instruction. The prescription is a \"proposed\" treatment, whereas the medication statement is a retrospective view/what the patient actually took (dosage/frequency).\r\nPSS: This is captured in treatment history, which captures the discrete dosage, time interval\r\n\r\nExample - Anti-depressant. Ramp up approach. This can be represented as 2 med statements; the first is the ramp up period and the second being the final dosage. Alternatively, this could be one med statement with two dosage lines (first this, then that). \r\n\r\n\r\nEXAMPLES: \r\nhttps://simplifier.net/onlyfortestingmedication/medicationstatement-example\r\nhttps://build.fhir.org/ig/HL7/ccda-on-fhir-r4//MedicationStatement-medication-statement.xml.html\r\nhttps://fhir.ch/ig/ch-emed/MedicationStatement-2-7-MedStatBeloczok.xml.html\r\nhttps://simplifier.net/finnishphr/medicationstatement-example-max\r\n\r\nPHARMACY WORKING GROUP FHIR - https://confluence.hl7.org/display/PHAR/May+2020+-+Virtual+Pharmacy+Meetings\r\n\r\n** THE .wasNotTaken DATA ELEMENT NO LONGER EXISTS; WAS REMOVED IN R3\r\n\r\nUse Case 1 - Sending Patient Chart to Specialist: Send \"active\" medications always and any relevant completed medications that pertain to the specific case. May wish to share \"intended\" as well. \r\nUse Case 2 - Sharing full Patient Chart (eg switching physicians). ALL history/all status's will be sent.\r\nUse Case 3 - DW - only \"active\" medications will be shared; will could be extended in the future\r\n\r\nEMR will not be aware of whether a drug is taken or not taken. PSS will know whether it was prescribed but not taken; it is then discontinued. \r\n\r\nMA - would support one medication statement, per prescription recorded in the EMR. If there is no prescription recorded (\"external prescription\"), this would be a single medication statement for each record.\r\n\r\nWe can SEND: \r\nStatus=Active = Taking (as of today's date) \r\nStatus=Completed = Taken in past (no future prescription, was a prescription in past)\rStatus=Active + NotTaken=T = Not currently taking \rStatus=Completed + NotTaken=T = Not taken in the past\rStatus=Intended = No intention of taking\rStatus=Active + NotTaken=F = Taking, but not as prescribed\rStatus=Active + NotTaken=F = Taking\rStatus=Intended +NotTaken= F = Will be taking (not started)\rStatus=Completed + NotTaken=F = Taken in past\rStatus=In Error + NotTaken=N/A = In Error.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.id",
"path" : "MedicationStatement.id",
"mustSupport" : true
},
{
"id" : "MedicationStatement.meta",
"path" : "MedicationStatement.meta",
"mustSupport" : true
},
{
"id" : "MedicationStatement.meta.lastUpdated",
"path" : "MedicationStatement.meta.lastUpdated",
"mustSupport" : true
},
{
"id" : "MedicationStatement.meta.source",
"path" : "MedicationStatement.meta.source",
"mustSupport" : true
},
{
"id" : "MedicationStatement.meta.profile",
"path" : "MedicationStatement.meta.profile",
"comment" : "Usage: Each implementation will determine if this will be used. It may be useful to validate a message instance against this profile.\r\n\r\nIt is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set.",
"max" : "1",
"mustSupport" : true
},
{
"id" : "MedicationStatement.text",
"path" : "MedicationStatement.text",
"comment" : "************ lots of work to be done on narrative in ALL Resources to ensure it can be summarized into a bigger picture for recipients who cannot accept discrete data\r\n\r\nCA-Core - not supported\r\nDiscussion: Important for mapping into CDA with CDX \r\n\r\nContained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a \"text blob\" or where text is additionally entered raw or narrated and encoded information is added later.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.text.status",
"path" : "MedicationStatement.text.status",
"mustSupport" : true
},
{
"id" : "MedicationStatement.text.div",
"path" : "MedicationStatement.text.div",
"mustSupport" : true
},
{
"id" : "MedicationStatement.extension",
"path" : "MedicationStatement.extension",
"slicing" : {
"discriminator" : [
{
"type" : "value",
"path" : "url"
}
],
"rules" : "open"
},
"min" : 0
},
{
"id" : "MedicationStatement.extension:RenderedDosageInstruction",
"path" : "MedicationStatement.extension",
"sliceName" : "RenderedDosageInstruction",
"definition" : "Concatenation of all dosage lines in a human readable form.",
"comment" : "Alignment: This is a pre-adoption of an R5 element; this is also prsent in PrescribeIT",
"min" : 0,
"max" : "1",
"type" : [
{
"code" : "Extension",
"profile" : [
"http://telus.com/fhir/patientChart/StructureDefinition/ext-rendered-dosage-instruction"
]
}
],
"isModifier" : false
},
{
"id" : "MedicationStatement.basedOn",
"path" : "MedicationStatement.basedOn",
"comment" : "Usage: The detailed prescription should be shared when known. This may be a prescription from the sending system, or a prescription that was imported from another system or recorded by the clinician (eg 'external prescription'). \r\n\r\nCA-Core - not supported but they are supporting derived from - ?\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.basedOn.reference",
"path" : "MedicationStatement.basedOn.reference",
"mustSupport" : true
},
{
"id" : "MedicationStatement.partOf",
"path" : "MedicationStatement.partOf",
"comment" : "Alignment: This data element will be supported for DW Extract. Not supported by Core-CA\r\n\r\nPatient Chart This data element will not be used as we have scoped med statement to particular use when patient advises of a medication they are taking and there is no prescription that has been created. \r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
},
{
"id" : "MedicationStatement.status",
"path" : "MedicationStatement.status",
"comment" : "Conformance Rule: For Patient Chart, only \"completed\" is supported; other status's (active | on-hold | cancelled | completed | entered-in-error | stopped | draft | unknown) will be conveyed in the Medication Request.status of the associated Plan. Rationale: In R5, many of these status's will no longer be supported\r\n\r\nFor Dw, this is a list of medications that the patient is currently taking, is planning to take or has taken. As such all status's are relevent.\r\n\r\nNote: The restricted code set aligns with R5, MedicationUsage. \r\n\r\nConformance Rule: Status of unknown and entered-in-error will not be sent for the Patient Chart. Rationale: EMRs do not have an indicator for unknown and entered-in-error are not clinically relevant or have been removed from the chart\r\n\r\n Medication Statement used to capture a change in medication at a given date. Example: There may be one \"active\" med statements for the same drug, with effective date \"x\" and another \"completed\" med statement with where dosage instructions have changed. \r\n\r\nFDG: what statuses would be considered as active (ex: recently active? Added to issues list\r\nConformance Rule: FDG *** confirm what status's are expected to be shared. Added to issues list\r\n\r\nMappings: \r\nEMRAPI: Status (CC)\r\nCA-Core: supported\r\n\r\nPSS - Discuss in FDG to confirm what status are appropriate. Active-> Active, completed->N/A N/A-> Inactive (won't show in CPP). entered-in-error-> N/A intended-> N/A stopped->Auto-discontinue ??--> discontinue (may or may not be codified, ask FDG for guidence), on hold-> on hold unknown-> N/A not taken-> \"not currently taking\" (compliance, not codified)\r\n\r\nMS : See value from Medication object. active -> active completed -> check stopped date in the past entered-in-error-> N/A\r\nintended -> N/A stopped -> stop (check SIG field in prescriber) on-hold -> N/A unknown -> N/A not-taken-> N/A. Looks for deactivation date. If deactivation date is null it is considered active.\r\n\r\nMA - Active - specific logic to drive active or inactive. Falls from active to inactive (dynamic/derived), based on calc based on end date and half-life of a drug (time it takes for drug to disappear 50% in patient's system). Discontinue=stopped. Hold=on-hold. Inactive=completed. Manual interventions (discontinue, renew) are also part of the logic. Example: Renewal -> instance of inactive /effective period+ instance of activ/start date _>> Two medication statements\r\n\r\nExample: RX/dose 1, then renew same RX/dose2 with overlap effectiveDate -> renewal would always replace the first one, and this would be a single med statement. \r\nCHR - if re-presecribing, replacing the original; implicitly end and start; can technically be represented either way.\r\nWarfarin - 1mg tab and 5mg tab - different med; different RX, \r\nWarafin - 1mg tab, second RX, 1mg tab - replace - single line, single med statement, start date from original\r\nEnd date is not definitive (eg if on hold, end date is bumped) - auto-calc\r\nMA - Early renewal. if you take meds with days remaining, and then renew, it defaults the start date of next RX to be the expected end date. 2 med statements in MA. To make this a single med statement, heuristic 1 med statement in PSS\r\n\r\n\r\nFor FDG: what statuses would be considered as active (ex: recently active?)\r\n\r\nCore-CA - supported\r\n\r\nFHIR: MedicationStatement is a statement at a point in time. The status is only representative at the point when it was asserted. The value set for MedicationStatement.status contains codes that assert the status of the use of the medication by the patient (for example, stopped or on hold) as well as codes that assert the status of the medication statement itself (for example, entered in error).\r\rThis element is labeled as a modifier because the status contains codes that mark the resource as not currently valid.",
"fixedCode" : "completed",
"mustSupport" : true
},
{
"id" : "MedicationStatement.statusReason",
"path" : "MedicationStatement.statusReason",
"comment" : "Usage Rule: This is supported as text only \r\nAlignment: This is not supported in the Core-CA; also support for DW Extract\r\n\r\nThis is generally only used for \"exception\" statuses such as \"not-taken\", \"on-hold\", \"cancelled\" or \"entered-in-error\". The reason for performing the event at all is captured in reasonCode, not here.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.statusReason.text",
"path" : "MedicationStatement.statusReason.text",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.category",
"path" : "MedicationStatement.category",
"comment" : "Mappings:\r\nCore-CA - not supported\r\nEMRAPI: N/A\r\nMA: N/A\r\nPSS: N/A \r\nMS: N/A\r\n \r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination."
},
{
"id" : "MedicationStatement.medication[x]",
"path" : "MedicationStatement.medication[x]",
"comment" : "Conformance Rule: This will be the \"prescribed\" medication, rather than the \"dispensed\" medication. The dispensed medication is assumed to be equivalent and therefore is not relevant to the medication statement. \r\n\r\nDISCUSSION\r\nIPS - has added an absent reason slice - https://build.fhir.org/ig/HL7/fhir-ips/ValueSet-absent-or-unknown-medications-uv-ips.html\r\nto convey \"no medication info\" or \"no known reasons\".\r\n\r\nADD A SLICE (codeable concept) - AS PER IPS AND MAYBE CANADIAN CORE? FOR THIS\r\n\r\nIPS value set:\r\nno-medication-info No information about medications There is no information available about the subject's medication use or administration.\r\nno-known-medications No known medications There are no medications for the subject that have to be reported in this record. This can mean either that there are none known, or that those known are not relevant for the purpose of this record.\r\n\r\n\r\nMS - does not capture explictly - could map to no-medication-info\r\nMA - ?\r\nPSS - ?\r\n \r\n\r\nJIM -- DO WE WANT TO SUPPORT THIS EXTENSION TO CONVEY NO MEDICATION INFO? alternatively we could put a null flavour on the reference from composition\r\n\r\nCore-CA - supported\r\n\r\nIf only a code is specified, then it needs to be a code for a specific product. If more information is required, then the use of the medication resource is recommended. For example, if you require form or lot number, then you must reference the Medication resource.",
"type" : [
{
"code" : "CodeableConcept"
},
{
"code" : "Reference",
"aggregation" : [
"contained"
]
}
],
"mustSupport" : true
},
{
"id" : "MedicationStatement.subject",
"path" : "MedicationStatement.subject",
"comment" : "Core-CA - supported\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.",
"type" : [
{
"code" : "Reference",
"targetProfile" : [
"http://hl7.org/fhir/StructureDefinition/Patient"
],
"aggregation" : [
"bundled"
]
}
],
"mustSupport" : true
},
{
"id" : "MedicationStatement.subject.reference",
"path" : "MedicationStatement.subject.reference",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.subject.display",
"path" : "MedicationStatement.subject.display",
"comment" : "Usage Note: This should contain the name of the Patient, which can then be used in narrative\r\n\r\nThis is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.context",
"path" : "MedicationStatement.context",
"comment" : "EMRAPI: Not supported \r\nCore-CA; Not supported\r\nPSS - Encounters are available via stamps and custom forms.\r\nMA, MS - N/A\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository."
},
{
"id" : "MedicationStatement.effective[x]",
"path" : "MedicationStatement.effective[x]",
"comment" : "Conformance Rule: This may be a fuzzy start date where the patient does not know exactly when the medication began. \r\nUsage Note: The default rule is that the most recent effective date (Prescribed/renewed date) should be used for episodic events, eg repeated bladder infection \r\n\r\nMed Statement. effective Period\r\n*if no end date, this is ACTIVE OR ON-HOLD in the plan; med statement is a fixed status of \"completed\"\r\n*IF end date is present AND Med Statement Date is less than= end date then it is ACTIVE in the plan\r\n*If end date is present AND Med Statement date is greater than end date, then it is COMPLETED in the plan\r\n If status Start date (of active record) and date the record was marked as completed \r\n\r\nAlignment-PS-ON: Question to them: If it is an episodic drug, what is expected? Most recent \r\nepisode, or original episode dates? Example: repeated bladder infections. Please update the specification to clarify\r\nAnswer from ON: Clinical consultation will be required to provide guidance for this. Ontario Health will look for opportunities to seek clinical guidance in the future.\r\n\r\n\r\nThis attribute reflects the period over which the patient consumed the medication and is expected to be populated on the majority of Medication Statements. If the medication is still being taken at the time the statement is recorded, the \"end\" date will be omitted. The date/time attribute supports a variety of dates - year, year/month and exact date. If something more than this is required, this should be conveyed as text.",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.dateAsserted",
"path" : "MedicationStatement.dateAsserted",
"comment" : "EMRAPI: N/A\r\nCore-CA - supported\r\nMA/MS: n/a\r\n\r\nPSS: One of 3 sources: a)\"Prescribed on Date\" may be used for medications that were prescribed by the doctor. b) For other recorded medications, the change date may be used. c) Date Issued may be used when treatment is entered via the Fast Profile Entry. Date when the patient told the PCP about it. \r\nFDG: Unless we really need this we can drop it.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.informationSource",
"path" : "MedicationStatement.informationSource",
"comment" : "Conformance Rule: If the EMR is able to distinguish that the patient was the information source of the medication information (eg entered by the patient in the patient portal or into a e-questionnaire/qnaire), then the information source must be the patient.\r\n\r\nConformance Rule: This is only expected to be populated with the patient or related person (mother, child) or an organization in the case of a nursing home when discretely recorded in the EMR. If the information source is not discretely \r\n\r\nCore-CA - supported\r\nDHDR - is this the Pharmacy?\r\n\r\n\r\nReferences SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.",
"type" : [
{
"code" : "Reference",
"aggregation" : [
"bundled"
]
}
],
"mustSupport" : true
},
{
"id" : "MedicationStatement.informationSource.reference",
"path" : "MedicationStatement.informationSource.reference",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.informationSource.display",
"path" : "MedicationStatement.informationSource.display",
"mustSupport" : true
},
{
"id" : "MedicationStatement.derivedFrom",
"path" : "MedicationStatement.derivedFrom",
"comment" : "Conformance Rule: This is supported in order to align with the CA-Core profile. To date, we do not have a specific use case for inclusion of this data. There is no expectation that this will be supported at this time for this implementation, though it may be used in other implementations in Canada.\r\n\r\nCore-CA - supported and also supported in US Core. CA- Core has scoped to support MedRequest, MedDispense, Claim, ObservationProfile (General Use)\r\n\r\nLikely references would be to MedicationRequest, MedicationDispense, Claim, Observation or QuestionnaireAnswers. The most common use cases for deriving a MedicationStatement comes from creating a MedicationStatement from a MedicationRequest or from a lab observation or a claim. it should be noted that the amount of information that is available varies from the type resource that you derive the MedicationStatement from.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.derivedFrom.reference",
"path" : "MedicationStatement.derivedFrom.reference",
"mustSupport" : true
},
{
"id" : "MedicationStatement.derivedFrom.display",
"path" : "MedicationStatement.derivedFrom.display",
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode",
"path" : "MedicationStatement.reasonCode",
"comment" : "Conformance Rule: A local code must be included if known. Text must also be included where known.\r\nCore-CA - not supported\r\nPSS: Local codes or for free text just send display. PSS: ICD9/10, SNOMED via FDB, encode\r\nMA: ICD9, SNOMED, free text, local code system\r\nMS: N/A\r\nDHDR: ODB reason for use code\r\n\r\nThis could be a diagnosis code. If a full condition record exists or additional detail is needed, use reasonForUseReference.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode.coding",
"path" : "MedicationStatement.reasonCode.coding",
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode.coding.system",
"path" : "MedicationStatement.reasonCode.coding.system",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode.coding.code",
"path" : "MedicationStatement.reasonCode.coding.code",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode.coding.display",
"path" : "MedicationStatement.reasonCode.coding.display",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonCode.text",
"path" : "MedicationStatement.reasonCode.text",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.reasonReference",
"path" : "MedicationStatement.reasonReference",
"comment" : "Core-CA - not supported\r\n\r\n\r\nThis is a reference to a condition that is the reason why the medication is being/was taken. If only a code exists, use reasonForUseCode."
},
{
"id" : "MedicationStatement.note",
"path" : "MedicationStatement.note",
"comment" : "Usage Notes: Used to capture any information from the patient that is pertinent to the statement. Information that is specific to dosage should be captured under dosage where possible. Example: Some EMRs record whether the medication is \"successful\" or \"not successful\" and general text comments that may be captured here. \r\n\r\nEMRAPI: Notes\r\nCore-CA - not supported\r\n\r\nMA: Patient instructions go in the dosage object\r\nPSS: Any comment can be added into medication, in addition the dosage.text/SIG? \r\nMS: Patient chart-->summary-->active medication --> comment\r\n\r\n\r\nFor systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. *Annotations SHOULD NOT* be used to communicate \"modifying\" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage",
"path" : "MedicationStatement.dosage",
"comment" : "Conformance Rule: This is the dosage that the patient actually took, which may differ than the dosage that is on the prescription.\r\nConformance Rule: This must always be included where known\r\n\r\n\r\nCore-CA - supported - text only is supported \r\n\r\nUsage: It is rare that a medication statement, will not have dosage (minimally text), but it may occur. \r\n\r\nUsage: This captures what the patient is actually taking. This COULD be the same as the dosage in the prescription (steady, ramp-up, ramp-down). If there is a change after the patient has started to take it, it is recorded in the EMR (not included in the prescription)\r\n\r\nUsage: Dosage instruction can be a single instance, with multiple dosage instructions/lines (eg one a night for 7 nights, then 2/day)\r\nUsage: Unexpected Dosage change - update to the dosage from the prescription. This would be recorded in the EMR and would have a different effective period. This is a trigger to send a new medication statement. \r\n*** For MS, this will be challenging; you dont' have a sense of history. eg active meds have an end date in 2017. RX for ongoing drug; renewal deactivates the previous one without changing dates on the old one or adapting on the new one (if you had the drug for years, it creates a new record)\r\n*** PSS - dosage/renewals are separate line; works well for a new med statement. \r\n\r\nConformance Rule: Where possible, each renewal could be a new/second med statement if the dosage changes.\r\nConformance Rule: Where possible, If the same drug, same dosage, many RX's, this can be rolled up and effective period would start at first RX. \r\n\r\nNotes: SIG can change multiple times for a single prescription. Doctors have the ability to change dosages and the prescription dosage is only valid at the time of writing and can be overridden at any point in the future. Prescription is a single event in the series of events that occur for that drug. including dosage instructions. Dosage instructions can be changed at any time; update/change within the system. Events: Prescription, Dosage Change, On-Hold, Discontinued, StartedAgain, etc.\r\n\r\nConformance Rule: If sending systems are capable, they should send the discrete data. This will be captured using the same mechanisms as PrescribeIT. Rationale: this may be useful for dosage checking and monitoring compliance to guidelines.\r\nUsage Note: An Excel spreadsheet published by PrescribeIT provides guidance on how to populate dosage instructions.\r\n\r\nMappings:\r\nIPS - support text, timing and route - https://build.fhir.org/ig/HL7/fhir-ips/StructureDefinition-MedicationStatement-uv-ips.html\r\n\r\n\r\nWhen the dose or rate is intended to change over the entire administration period, e.g. Tapering dose prescriptions, multiple instances of dosage instructions will need to be supplied to convey the different doses/rates. Another common example in institutional settings is 'titration' of an IV medication dose to maintain a specific stated hemodynamic value or range e.g. drug x to be administered to maintain AM (arterial mean) greater than 65.\r\n\r\nThe dates included in the dosage on a Medication Statement reflect the dates for a given dose. For example, \"from November 1, 2016 to November 3, 2016, take one tablet daily and from November 4, 2016 to November 7, 2016, take two tablets daily.\" It is expected that this specificity may only be populated where the patient brings in their labeled container or where the Medication Statement is derived from a MedicationRequest.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.sequence",
"path" : "MedicationStatement.dosage.sequence",
"comment" : "Usage Note: This is mandatory as it indicates the dosage instruction sequence.\r\n\r\nMapping Note: This concept is represented in PrescribeIT as an extension on dosage. Core-CA - not supported ?\r\n \r\n 32 bit number; for values larger than this, use decimal",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.text",
"path" : "MedicationStatement.dosage.text",
"comment" : "Conformance Rule: When providing multiple dosage lines can be expressed individually. All dosage lines (full text content) must be concatenated into MedicationStatement.extension(RenderedDosageInstruction) for recipients who can support the receipt of individual lines.\r\n\r\nUsage Note: This is a string composed of any available discrete MedicationStatement.dosage child elements such as timing, asNeeded[x], siteCodeableConcept, route, dose[x], rate[x], and maxDosePerPeriod for each repetition sequence line.\r\n\r\nExample: Prednisone; variable dosage instruction, or concurrent instructions (1 pill morning and 1 pill before bed) or sequential dosages (1 pill for 2 days, then 2 pills).",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.additionalInstruction",
"path" : "MedicationStatement.dosage.additionalInstruction",
"comment" : "EMRAPI: Not supported\r\nCore-CA - not supported\r\n\r\nPrescribeIT Usage Notes below - MAY NOT BE ALL APPROPRIATE; DISCUSSION REQUIRED\r\n\r\nUsage Note:: To convey explicit instructions to the Pharmacist/dispenser related to this medication order.\r\n\r\nUsage Note: If the PMS solution is unable to display the entire instructions, then it is expected that the current solution has a fail-over process and will create a printout of the prescription.\r\n\r\nConformance Rule: When 'compliance pack' is indicated on the prescription within the EMR, populate the pharmacist instruction/dispenser instructions with 'COMPLIANCE PACK REQUESTED'\r\n\r\nUsage Note: In the case where the prescriber indicates the concept of ‘do not adapt’ (meaning that the pharmacist should not alter the prescription based on the patient's weight as an example), this direction to the pharmacist should be conveyed in human language in this field.\r\n\r\nConformance Rule: If a prescriber wishes to indicate that there is no substitution it must be included as part of the pharmacy instructions.\r\n\r\nConformance Rule: LU Codes must be clearly conveyed as part of the Pharmacists Instructions. If vendors are programmitically mapping into this field, they should use a prefix of LU Code before the identifier.\r\n\r\nInformation about administration or preparation of the medication (e.g. \"infuse as rapidly as possibly via intraperitoneal port\" or \"immediately following drug x\") should be populated in dosage.text.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.patientInstruction",
"path" : "MedicationStatement.dosage.patientInstruction",
"comment" : "Core-CA - not supported\r\n\r\nDiscussion required: \r\nPSS: Label Instruction. Note: this is also part of text. Note, with meals\", \"may cause drowsiness are included here but FHIR shows under additional instructions.\r\n\r\nNote that FHIR strings SHALL NOT exceed 1MB in size",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing",
"path" : "MedicationStatement.dosage.timing",
"comment" : "Core-CA - not supported\r\n\r\nConformance Rule: If an EMR cannot send discrete elements in all cases for timing.repeat element, this is acceptable as long as RENDERED_DOSAGE_INSTRUCTION captures the timing.\r\n\r\nThis attribute might not always be populated while the Dosage.text is expected to be populated. If both are populated, then the Dosage.text should reflect the content of the Dosage.timing.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat",
"path" : "MedicationStatement.dosage.timing.repeat",
"comment" : "Conformance Rule: If an EMR cannot send discrete elements in all cases for timing.repeat element, this is acceptable as long as RENDERED_DOSAGE_INSTRUCTION captures the timing.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.bounds[x]",
"path" : "MedicationStatement.dosage.timing.repeat.bounds[x]",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.count",
"path" : "MedicationStatement.dosage.timing.repeat.count",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.countMax",
"path" : "MedicationStatement.dosage.timing.repeat.countMax",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.duration",
"path" : "MedicationStatement.dosage.timing.repeat.duration",
"comment" : "Example: \"5 mL Q6H for 4 day(s)\"\r\n\r\nFor some events the duration is part of the definition of the event (e.g. IV infusions, where the duration is implicit in the specified quantity and rate). For others, it's part of the timing specification (e.g. exercise).",
"requirements" : "API Mapping: *.currentMedications.dosageInstructions.duration.value\r\n\r\nSome activities are not instantaneous and need to be maintained for a period of time.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.durationMax",
"path" : "MedicationStatement.dosage.timing.repeat.durationMax",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.durationUnit",
"path" : "MedicationStatement.dosage.timing.repeat.durationUnit",
"comment" : "Example: \"5 mL Q6H for 4 day(s)\"\r\n\r\nNote that FHIR strings SHALL NOT exceed 1MB in size",
"requirements" : "API Mapping: *.currentMedications.dosageInstructions.duration.unit.coding\r\n\r\nUnit of time (required)\r\ns/min/h/d/wk/mo/ a \r\nMA: urn:telus:emr:ma:*:codetable:medication-frequency\r\nPSS: urn:telus:emr:pss:*:codetable:dose-duration",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.frequency",
"path" : "MedicationStatement.dosage.timing.repeat.frequency",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.frequencyMax",
"path" : "MedicationStatement.dosage.timing.repeat.frequencyMax",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.period",
"path" : "MedicationStatement.dosage.timing.repeat.period",
"requirements" : "5 mL Q6H for 4 day(s)\"\r\nAPI doesn't break this out by period and period unit.\r\nAPI Mapping: *.currentMedication.doageInstructions.frequency.coding",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.periodMax",
"path" : "MedicationStatement.dosage.timing.repeat.periodMax",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.repeat.periodUnit",
"path" : "MedicationStatement.dosage.timing.repeat.periodUnit",
"comment" : "5 mL Q6H for 4 day(s)\"\r\n****Don't think API frequency value will work as it is a single code and doesn't break out both the amount and unit.\r\n\r\nNote that FHIR strings SHALL NOT exceed 1MB in size",
"requirements" : "API Mapping: *.currentMedication.doageInstructions.frequency.coding",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.code",
"path" : "MedicationStatement.dosage.timing.code",
"comment" : "EMRAPI: *.currentMedication.doageInstructions.frequency.coding\r\n\r\n??? this is NOT supported in PrescriebIT, so we need to revisit to ensure we need this. Mapping is pretty clear\r\n**Maybe API frequency element would be better used here?\r\n\r\nBID etc. are defined as 'at institutionally specified times'. For example, an institution may choose that BID is \"always at 7am and 6pm\". If it is inappropriate for this choice to be made, the code BID should not be used. Instead, a distinct organization-specific code should be used in place of the HL7-defined BID code and/or a structured representation should be used (in this case, specifying the two event times).",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.code.coding",
"path" : "MedicationStatement.dosage.timing.code.coding",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.timing.code.coding.code",
"path" : "MedicationStatement.dosage.timing.code.coding.code",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.asNeeded[x]",
"path" : "MedicationStatement.dosage.asNeeded[x]",
"comment" : "Core-CA - not supported\r\n\r\nEMRAPI: .currentMedications.dosageInstructions.asNeeded\r\n\r\nUsage Note: \r\n\r\nFHIR: Can express \"as needed\" without a reason by setting the Boolean = True. In this case the CodeableConcept is not populated. Or you can express \"as needed\" with a reason by including the CodeableConcept. In this case the Boolean is assumed to be True. If you set the Boolean to False, then the dose is given according to the schedule and is not \"prn\" or \"as needed\".",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.site",
"path" : "MedicationStatement.dosage.site",
"comment" : "Core-CA \r\n\r\n- not supportedIf the use case requires attributes from the BodySite resource (e.g. to identify and track separately) then use the standard extension [bodySite](extension-bodysite.html). May be a summary code, or a reference to a very precise definition of the location, or both.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.site.coding",
"path" : "MedicationStatement.dosage.site.coding",
"max" : "1",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.site.text",
"path" : "MedicationStatement.dosage.site.text",
"min" : 1
},
{
"id" : "MedicationStatement.dosage.route",
"path" : "MedicationStatement.dosage.route",
"comment" : "EMRAPI: *.currentMedications.route\r\nCore-CA - not supported\r\n\r\nNot all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.route.coding",
"path" : "MedicationStatement.dosage.route.coding",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.route.text",
"path" : "MedicationStatement.dosage.route.text",
"min" : 1,
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.method",
"path" : "MedicationStatement.dosage.method",
"comment" : "Core-CA - not supported\r\n\r\nTerminologies used often pre-coordinate this term with the route and or form of administration."
},
{
"id" : "MedicationStatement.dosage.doseAndRate",
"path" : "MedicationStatement.dosage.doseAndRate",
"comment" : "EMRAPI: *.dosageInstructions.doseRangeLow and *.doseRangeHigh\r\nCore-CA - not supported",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.doseAndRate.dose[x]",
"path" : "MedicationStatement.dosage.doseAndRate.dose[x]",
"requirements" : "API Mapping: *.dosageInstructions.quantity\r\n*.dosageInstructions.doseRangeLow \r\n\r\nFHIR: The amount of therapeutic or other substance given at one administration event.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.doseAndRate.rate[x]",
"path" : "MedicationStatement.dosage.doseAndRate.rate[x]",
"comment" : "Example: \"5 mL Q6H for 4 day(s)\"\r\n\r\nPrescribeIT - always a ratio I think\r\n\r\nIt is possible to supply both a rate and a doseQuantity to provide full details about how the medication is to be administered and supplied. If the rate is intended to change over time, depending on local rules/regulations, each change should be captured as a new version of the MedicationRequest with an updated rate, or captured with a new MedicationRequest with the new rate.\r\rIt is possible to specify a rate over time (for example, 100 ml/hour) using either the rateRatio and rateQuantity. The rateQuantity approach requires systems to have the capability to parse UCUM grammer where ml/hour is included rather than a specific ratio where the time is specified as the denominator. Where a rate such as 500ml over 2 hours is specified, the use of rateRatio may be more semantically correct than specifying using a rateQuantity of 250 mg/hour.",
"mustSupport" : true
},
{
"id" : "MedicationStatement.dosage.maxDosePerPeriod",
"path" : "MedicationStatement.dosage.maxDosePerPeriod",
"comment" : "Core-CA - not supported\r\n\r\nThis is intended for use as an adjunct to the dosage when there is an upper cap. For example \"2 tablets every 4 hours to a maximum of 8/day\"."
},
{
"id" : "MedicationStatement.dosage.maxDosePerAdministration",
"path" : "MedicationStatement.dosage.maxDosePerAdministration",
"comment" : "Core-CA - not supported\r\n\r\nThis is intended for use as an adjunct to the dosage when there is an upper cap. For example, a body surface area related dose with a maximum amount, such as 1.5 mg/m2 (maximum 2 mg) IV over 5 – 10 minutes would have doseQuantity of 1.5 mg/m2 and maxDosePerAdministration of 2 mg."
}
]
},
"text" : {
}
}
XIG built as of ??metadata-date??. Found ??metadata-resources?? resources in ??metadata-packages?? packages.